home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / iesg / iesg.93-06-24 < prev    next >
Encoding:
Text File  |  1993-08-27  |  10.0 KB  |  265 lines
  1.  
  2.  
  3.             Internet Engineering Steering Group (IESG)
  4.  
  5.                 Report from the IESG Teleconference
  6.  
  7.                          24 June 1993
  8.  
  9.          Recorded by:  John Stewart, IESG Secretary
  10.  
  11. This report contains IESG meeting notes, positions and action items.
  12.  
  13. These minutes were compiled by the IETF Secretariat, which is supported
  14. by the National Science Foundation under Grant No. NCR 8820945.
  15.  
  16. For more information please contact the IESG Secretary.
  17. iesg-secretary@cnri.reston.va.us.
  18.  
  19. ATTENDEES
  20. ---------
  21.     Bradner, Scott / Harvard
  22.     Chapin, Lyman / BBN
  23.     Coya, Steve / CNRI
  24.     Crocker, Dave / SGI
  25.     Crocker, Steve / TIS
  26.     Gross, Philip / ANS
  27.     Huizer, Erik / SURFnet
  28.     Klensin, John / UNU
  29.     Knowles, Stev / FTP Software
  30.     Mankin, Allison / Locus 
  31.     Rose, Marshall / DBC
  32.     Stewart, John / CNRI
  33.     Vaudreuil, Greg / CNRI
  34.  
  35. IAB Liaison
  36.     Christian Huitema / INRIA
  37.     Yakov Rekhter / IBM
  38.  
  39. Regrets
  40.     Hinden, Robert / SUN
  41.     Piscitello, Dave/ Bellcore
  42.     Reynolds, Joyce / ISI
  43.  
  44.  
  45. Minutes
  46. -------
  47.  
  48. 1. Administrative Issues
  49.  
  50.    o Roll Call
  51.  
  52.    o Revisions to the Agenda
  53.  
  54.    o Approval of the Minutes
  55.  
  56.       - The minutes of the 13 May, 27 May, and 10 June
  57.          IESG teleconferences were approved.
  58.  
  59.    o Scott Bradner will not be in Amsterdam
  60.  
  61.    o The IESG/IAB lunch in Amsterdam will be Wednesday
  62.       14 July; probably in the RAI for convenience.
  63.  
  64. 2. Protocol Actions
  65.  
  66.    o The IESG approved the elevation of the MIME Internet-
  67.       Drafts ("MIME Part 1" and "MIME Part 2") to the status
  68.       of Draft Standard.
  69.  
  70.    o The IESG approved the MIME-MHS Internet-Drafts ("Mapping
  71.       between X.400 and RFC-822 Message Bodies," "Equivalences
  72.       between 1988 X.400 and RFC-822 Message Bodies," and
  73.       "HARPOON:  Rules for downgrading messages from X.400/88
  74.       to X.400/84 when MIME content-types are present in the
  75.       messages") for the status of Proposed Standard.
  76.  
  77.    o The IESG approved the "Content-MD5 Header" Internet-Draft
  78.       for the status of Proposed Standard.
  79.  
  80.    o The IESG approved the Common Authentication Technology
  81.       Internet-Draft ("Generic Security Service Application
  82.       Program Interface," "The Kerberos Network Authentication
  83.       Service (V5)," and "Generic Security Service API:
  84.       C-bindings") for the status of Proposed Standard.
  85.  
  86. 3. Working Group Actions
  87.  
  88.    o Multiparty Multimedia Session Control (mmusic) was
  89.       approved as a working group under the Transport Area.
  90.  
  91.    o Inter-Domain Multicast Routing (idmr) was approved as a
  92.       working group under the Routing Area.
  93.  
  94. 4. Working Group Informational Documents
  95.  
  96.    o Assertion of C=US; A=IMX <info>
  97.       Erik Huizer said that the technical quality of the
  98.       document is good, but there is a question about whether
  99.       documents whose scope is limited to one nation are in
  100.       the purview of the IESG/IETF.  After some discussion,
  101.       he said that he thinks it would be acceptable to
  102.       approve this document for Experimental status, but that
  103.       the IESG still needs to decide on a general policy for
  104.       how to deal with documents of significance to a single
  105.       nation.  One person noted that this could be thought of
  106.       analogous to NTP's current status; specifically,
  107.       something which is of good technical quality, but is
  108.       not appropriate or of interest to the entire IETF.  It
  109.       was also noted that if approving this document resulted
  110.       in interoperability across U.S. borders, then perhaps
  111.       it is not "just" pertinent to one nation.
  112.       
  113.       A question was brought up as to why the Internet needs
  114.       a node so high up in the naming tree; a comment was
  115.       also made that the ADMD=" " convention might break some
  116.       current implementations.  Naming in this context
  117.       involves policy issues which are decided by an ANSI /
  118.       U.S. State Department collaboration.
  119.  
  120. ACTION (Klensin, Chapin): Edit the document for any particular
  121. content and/or terminology which may be expected by the ANSI /
  122. U.S. State Department collaboration.
  123.  
  124.    o Guidelines for OSPF / Frame Relay <info>
  125.       No action to report.
  126.  
  127.    o Op Reqs for X.400 Mngmnt Domains in GO-MHS <info>
  128.       Erik Huizer has not yet read the document.  He will ask
  129.       John Klensin to look at it.
  130.  
  131. 5. Management Issues
  132.  
  133.    o HP's complaint about TELNET Environment Option
  134.       The crux of this problem is that the way the working group
  135.       documented the environment option was inadvertently
  136.       different than the reference implementation; the working
  137.       group's solution to the inconsistency was to change the
  138.       specification to match the implementation. This upset
  139.       Hewlett-Packard because they coded to the RFC.  It was
  140.       noted that this is a clash of cultures resulting from the
  141.       Internet's growth and attention by more parties.  The way
  142.       the IESG can address this issue in general is by setting
  143.       policies for acceptable types of changes to go from
  144.       Proposed to Draft and from Draft to Standard.  For this
  145.       specific case, the consensus was to allow the working
  146.       group to make the change, but to do so in recycling the
  147.       RFC back to Proposed (i.e., rather than going from
  148.       Proposed to Draft Standard).  Also, the working group will
  149.       have to address any interoperability problems before moving
  150.       up to Draft.  As a general procedural matter, it was agreed
  151.       that all organizations doing business with the IESG should
  152.       do so via electronic mail.
  153.  
  154. ACTION (Coya, Stewart): Draft a statement on acceptable types of
  155. changes that can happen when going from Proposed to Draft and
  156. from Draft to Standard.
  157.  
  158. ACTION (Huizer, Klensin): Inform the telnet working group of the
  159. IESG's discussion, and supply them with a revised version of the
  160. document to be drafted by Coya and Stewart.  This action should
  161. be taken before the IESG responds to Hewlett-Package.
  162.  
  163. ACTION (Gross): Respond to Hewlett-Packard's complaint after the
  164. document to be drafted by Coya and Stewart is completed, and
  165. after the telnet working group has been told of the IESG
  166. discussion.
  167.  
  168.    o IP over ARCNET <rfc1201> from Historic to Draft
  169.       Don Provan of Novell responded late to the Last Call
  170.       with information to the effect that there were as many
  171.       as five implementations of RFC1201.  This issue will
  172.       be tabled until the members of the IESG have a chance
  173.       to see Provan's message.
  174.  
  175. ACTION (Stewart): Send Don Provan's message to the IESG mailing
  176. list.
  177.  
  178.    o ATM Forum
  179.       Allison Mankin reported that the June 21-23 ATM Forum
  180.       meeting voted to object to the proposed IETF vc-routing 
  181.       charter of producing a routing protocol specification for 
  182.       ATM.  This vote was consonant with the view of the ATM
  183.       Forum's technical committee chair, Glenn Estes, who had
  184.       previously talked with her about his disagreement with
  185.       Fred Sammartino's (the President of ATM Forum's) position
  186.       on vc-routing.  As comment on the vote about IETF,
  187.       Estes has stated that IETF members are welcome to participate
  188.       in developing the standard in the ATM Forum, through their
  189.       companies' Forum memberships.  Standards contributions
  190.       can only be received from Forum members.  Further discussion  
  191.       on this will wait until Bob Hinden is able to participate.
  192.  
  193.       Christian Huitema reported that there was a similar discussion
  194.       in an IAB teleconference recently.
  195.  
  196. ACTION (Gross): Communicate the IESG's discussion on the IETF/ATM
  197. Forum issue to the IAB.
  198.  
  199. ACTION (Mankin, Gross, Hinden): Talk privately about the IETF/ATM
  200. Forum issue, and then contact the vc-routing proposed working group
  201. chairs.
  202.  
  203.    o Router Requirements Working Group
  204.       There has been no luck in contacting Phill Almquist, the
  205.       current chair of Router Requirements, to try and find the
  206.       working group's status.
  207.  
  208. ACTION (Knowles): Continue to try to contact Almquist.
  209.  
  210. ACTION (Gross, Rose, Knowles): Try to find new chair(s) and four
  211. editors.
  212.  
  213.    o BBN's request for ST-II demo 
  214.       Erik Huizer was concerned about BBN's last minute request
  215.       and logistically complex request to do an ST-II demo.
  216.  
  217.    o Second IESG Liaison to the IAB
  218.       During the period of the POISED activities, it was decided
  219.       that the IESG and IAB should each exchange 2 representatives
  220.       to participate on the other body.  This would include the 
  221.       respective chairs and one other member.
  222.  
  223.       During these discussions, Bob Hinden was nominated, and
  224.       tentatively agreed to serve, as the second IESG representative
  225.       on the IAB.  During this call, the IESG agreed to extend the
  226.       invitation to Bob.
  227.  
  228.       During the discussion, it was noted that the IAB decided that 
  229.       the IETF chair would have an ex-officio vote on IAB matters, but
  230.       the other IESG representative would not.  There was a brief 
  231.       related discussion about whether the IAB should vote, or even
  232.       participate, on the IESG.  Because the IAB plays a part in
  233.       appeals, some felt that this gave the IAB two votes.  There was
  234.       not enough of a discussion to come to consensus.
  235.  
  236. ACTION (Gross): Talk to Bob Hinden about being the second IESG
  237. liaison to the IAB.  (Note: Gross has since spoken to Hinden,
  238. and Hinden has agreed to serve.)
  239.  
  240.    o IETF Charter
  241.       Phill Gross is currently working on it.
  242.  
  243. ACTION (Gross): Present draft of the IETF Charter by Amsterdam.
  244.    
  245. 6. RFC Editor Actions
  246.  
  247.    o Simple Paging Protocol
  248.       There was consensus that work of this nature should be the
  249.       result of an IETF working group.  Some felt that there
  250.       were simpler ways to achieve the author's goal and that
  251.       another protocol was not necessary.  An extension will be
  252.       requested from the RFC Editor so that the IESG can contact
  253.       the author about participating in a working group effort.
  254.  
  255. ACTION (Stewart): Request an extension from the RFC Editor so
  256. that the IESG can talk to the author about participating in a
  257. working group.
  258.  
  259.    o Reverse Bootp
  260.       Dave Piscitello was not present, so there was little
  261.       discussion.
  262.  
  263. ACTION (Stewart): Request an extension from the RFC Editor so
  264. that we can get input from Dave Piscitello.
  265.